前言

為什麼要把 debug 拿出來說呢？
我發現其實 debug 的流程比較少人討論，
一般我們會看到的討論文章也只有 error log，
跟系列文章一樣，這邊也是教大家一些 debug 的技巧。

加速

很多人在 debug 的時候還是會選擇按 ，
但這其實是重新編譯並從 app 一開啟就進入 debug 模式，
可以在 app 開啟的狀態下按 ，
就會直接進入 debug 模式，不管有沒有進 debug 模式，也都可以動態加上中斷點。

有條件的中斷

有時候中斷點是下在迴圈裡面，
這樣即使一直按 F9 跳到下一次中斷也還是要花很多時間，
我們可以在中斷點上按右鍵，輸入停下來的條件。

evaluate（單步停下來後，按 ⌥+F8）

我們經常遇到以下情境：

• 遇到 bug 回報說一個情境遇到問題
• 視覺設計說要看列表 item 數量 0、多個
• 測試工程師說想知道空值或邊際值的情況

我們可以直接在 evaluate 裡面寫 code，像是：
修改變數

呼叫函式

修改 list

這樣做的優點是，我們就不需要 hard code（寫死）然後重新編譯，
節省時間也避免 hard code 沒有改回來的悲劇。

需要特別注意的是：

• 本來該走卻沒走的流程（當然也可以手動執行）。
• 被改完的變數會不會造成後續問題（比如數據搜集、打 api 後狀態變更）。

log 搜集

有時候用戶形容的情境我們無法理解，
我們也該建立一套記錄 log 的機制，
在合法的情況下（請與法務討論），
請用戶操作，回傳 log，
以便判斷流程以及遇到的問題。

結語

導致 app 出問題的可能性真的很多，
有的時候甚至跟自己服務都無關，像是用戶有開擋廣告的 app 導致 api 失效，
建議列出可以調查的方向，
像是內外網 api、舊版更新、裝置版本、短網址、協定等等，
至於在開發階段，我們盡量做到多測不同裝置、寫測試、考量不同情境，
祝各位永不遇到 timing issue、crash 都有 error log。